In computer science, “serialization” is the process of converting or translating an in-memory representation of a structured data model class (i.e., an “object”) into a standard external form that can be persisted and can be identified using an external type identifier. This serialization process is sometimes referred to as “deflating an object” or “marshalling an object.” The reverse process, extracting an in-memory representation of a data model class from a persisted standard external form identified by an external type identifier, is known as “deserialization,” “inflating an object,” or “unmarshalling an object.”
Data modeling software products have been developed for use in serialization and deserialization procedures. Such data modeling software products typically use a data structure, such as a registry, that associates external type identifiers with data model classes that define the data model's in-memory representation. The data modeling software then uses the data structure to identify the data model whose classes are to be instantiated and configured.
One example of a legacy data modeling software product is the Java™ language-based Eclipse Modeling Framework (EMF). From an external model specification, EMF provides tools and runtime support to produce a set of Java classes for the model. The EMF library converts model instances from a variety of external forms, such as XML, into an in-memory form consisting of one or more Java objects. In at least some configurations, the EMF library uses a registry to perform the translation. The registry keys are external type identifiers, such as uniform resource identifiers (URIs), and the registry values are the Java classes that define the model's in-memory representation. The EMF software for deserializing XML documents into Java objects will get the XML document's external type identifier, look up the external type identifier in the registry to find the external type identifier's corresponding Java object, and then has the Java object read the external information and convert it into one or more in-memory model objects. In cases where there are multiple nested model objects from different models, the EMF deserialization software may perform multiple registry lookups as it parses the XML.
Many software packages with this sort of functionality assume that any software needing to deserialize can simply look up information in the registry and be able to instantiate the matching in-memory model classes. Such software may also assume that all classes required to instantiate a particular model object are available for use. In a simple Java URL class loader environment this is indeed the case, and EMF uses this mechanism. In a more sophisticated dynamic class loader environment, however, software may be segregated into different “bundles.” Each bundle may be associated with configuration metadata describing, for example, the name of the bundle, the version of the bundle, and dependency information. Each bundle's metadata may then be used to calculate a dependency graph identifying a set of bundles upon which that bundle depends. This set of dependencies describes the classes that the bundle can instantiate, and limits the classes available to the bundle. In such a dynamic class loader environment, multiple versions of a particular bundle each have a separate existence and are capable of simultaneous use by other versions of other bundles in other dependency graphs. Such an environment may be described as having metadata-driven wiring.
One example of a more sophisticated dynamic class loader environment with metadata driven wiring is the OSGi Framework. The OSGi Framework is a class loader environment based on top of Java but, rather than supporting a single class path containing all classes, OSGi supports multiple bundle-specific class paths. The single registry approach of EMF may not work with OSGi's more sophisticated class loader environment. An EMF registry contains all possible external type identifiers and their corresponding model classes, of which there can only be one version per model. An OSGi software bundle trying to read a particular external model format would not be able to instantiate the corresponding in-memory representation if it did not have access to the requisite classes, even if those classes are in the single registry. If there are multiple versions of a particular bundle containing model classes, only one version is able to exist in the registry at a time, even if multiple versions of the bundle are present and available for use in the OSGi environment.